home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20010921-20020314
/
000074_fdc@watsun.cc.columbia.edu_Fri Oct 26 09:34:39 EDT 2001.msg
< prev
next >
Wrap
Text File
|
2020-01-01
|
3KB
|
61 lines
Article: 12887 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.unix.programmer,comp.protocols.tcp-ip,comp.unix.bsd.freebsd.misc,comp.protocols.kermit.misc
Subject: Re: resumable ftp ??
Date: 26 Oct 2001 13:22:49 GMT
Organization: Columbia University
Lines: 44
Message-ID: <9rbo39$q2a$1@newsmaster.cc.columbia.edu>
References: <3eb007f1.0110252012.40a46bd9@posting.google.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1004102569 26698 128.59.39.2 (26 Oct 2001 13:22:49 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 26 Oct 2001 13:22:49 GMT
Xref: newsmaster.cc.columbia.edu comp.os.linux.misc:523547 comp.os.linux.networking:360194 comp.unix.programmer:136791 comp.protocols.tcp-ip:94885 comp.unix.bsd.freebsd.misc:182759 comp.protocols.kermit.misc:12887
In article <3eb007f1.0110252012.40a46bd9@posting.google.com>,
Sony Antony <sonyantony@hotmail.com> wrote:
: While visiting HP site to download some drivers, I noticed them
: proclaiming about some "resumable download " feature at their site. I
: have seen something similar in netscape smart agent also.
: Essentially you can download part of it and then resume the remaining
: later.
:
: I was wondering if there is any ftp like standard protocol that
: allowes this. I ve felt this to be a shortcoming in ftp.
:
The widespread standard FTP protocol, RFC959, includes a REST (restart)
command. This lets the client request the server position its file pointer
to a given position before starting to send the next file. The client then
appends the incoming file to the incomplete part of the file whose download
was previously interrupted. This works only for binary-mode downloads
between stream-oriented file systems. For text ("ascii") mode transfers
between file systems with differing record format (e.g. LF vs CRLF line
terminators) this would produce a corrupt result.
For uploading, it's all done in the client.
Some servers (such as wu-ftpd and ProFTPD) support REST, some don't. Some
clients support REST, some don't. Some clients support recovery of
interrupted uploads, some don't. An example of an FTP client that supports
both upload and download recovery is C-Kermit 8.0:
http://www.columbia.edu/kermit/ftpclient.html
But of course download recovery also requires a server that supports REST.
RFC959 also alludes to a more flexible checkpoint/restart procedure, but I'm
not aware that it has ever been implemented.
The Kermit protocol is another one that supports recovery in both
directions, also only for binary-mode transfers. As with FTP, a more
complicated general-purpose checkpoint/restart mechanism has been designed
but never implemented due to lack of demand. As described in RFCs 2839 and
2840, Kermit servers can now be installed as Internet services, just like
ftpd, and have some distinct advantages over ftpd:
http://www.columbia.edu/kermit/cuiksd.html
- Frank